feat(core): implement parseMemory with structured section extraction#747
feat(core): implement parseMemory with structured section extraction#747Alexi5000 wants to merge 1 commit into
Conversation
Replace the stub parseMemory that returned `{ raw: markdown }` with
a real parser that extracts User Profile, Key Facts, Ongoing Context,
and MANUAL notes from the memory markdown format generated by
generateMemory(). Adds a typed ParsedMemory interface and exports it
from the core package.
|
Hi @Alexi5000 - I'm taking a look at the feature work in This comment is updated in place by pr-reviewer. |
PR-Reviewer-Ant
left a comment
PR-Reviewer-Ant
left a comment
There was a problem hiding this comment.
Review metadata
- Reviewer: pr-reviewer
- Model:
gpt-5.5 - Commit:
d92a828f
The implementation does not match the PR's stated parsing behavior for the generated memory template. In particular, parseMemory(generateMemory()) returns placeholder/comment content instead of empty section fields, and ongoingContext absorbs the manual-note block.
Confidence: High [sufficient_diff_evidence, targeted_context_included] - The changed parser reads every non-heading line after ## Ongoing Context until EOF, while generateMemory() places the manual block after that heading with no following ## heading. The PR test plan also explicitly expects parseMemory(generateMemory()) to return empty-string fields, which this implementation cannot do because it preserves the default placeholder lines as section content.
| const headingMatch = line.match(/^##\s+(.+)/); | ||
| if (headingMatch) { | ||
| // Flush previous section | ||
| if (currentSection !== null) { |
There was a problem hiding this comment.
This keeps collecting lines after ## Ongoing Context until another ## heading appears, but generateMemory() puts the <!-- MANUAL:START --> ... <!-- MANUAL:END --> block after Ongoing Context without a new heading. As a result, parseMemory(generateMemory()).ongoingContext includes the manual-marker comments, while manualNotes separately extracts the placeholder comment. That diverges from the PR's claim that the generated template parses into empty fields and gives consumers polluted section content.
|
|
||
| // Extract manual notes block | ||
| const manualMatch = markdown.match( | ||
| /<!--\s*MANUAL:START\s*-->([\s\S]*?)<!--\s*MANUAL:END\s*-->/, |
There was a problem hiding this comment.
The parser returns the generated placeholder text (*No user profile configured yet.*, *No facts stored yet.*, *No ongoing context.*) as real structured data. The PR test plan says parseMemory(generateMemory()) should return empty-string fields when no data is stored yet, so consumers will incorrectly treat the default template as populated memory.
2 participants
Summary
parseMemory()inplatform/core/src/memory.tswhich was a TODO stub returning{ raw: markdown }ParsedMemoryinterface with fields:userProfile,keyFacts,ongoingContext,manualNotes,raw##headings matching the template produced bygenerateMemory()<!-- MANUAL:START -->/<!-- MANUAL:END -->blockParsedMemorytype from the core package indexMotivation
The
parseMemoryfunction was marked as TODO and returned only the raw markdown string. This makes it impossible for consumers to programmatically access individual memory sections without re-parsing. The implementation follows the exact markdown structure defined bygenerateMemory().Test Plan
parseMemory(generateMemory())returns empty-string fields for each section (no data stored yet)parseMemory(md).raw === mdMANUAL:STARTandMANUAL:ENDare extracted